Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/osinsap/osinsap-minutes-90july.txt

Text File | 1993-02-17 | 6KB | 156 lines

CURRENT_MEETING_REPORT_


Reported by Jim Showalter/DCA

OSINSAP Minutes

The meeting was chaired by Richard Colella (NIST).

Agenda


   o Recording of Minutes
   o Status of the NSAP RFC
   o Status of the NSAP Guidelines Paper
   o Proposed NSAP Administration Paper
   o Address Transition Issues


Status of the NSAP RFC

Ross Callon (OSI Area Co-director/DEC) gave a brief status of the NSAP
RFC. The RFC, which supersedes RFC 1069, is a recommended structure for
OSI NSAPs for use in the Internet.  At present it is an Internet Draft
out for comment.  Ross proposed that the group recommend to the IESG
that the draft be progressed as an RFC. Although unrelated to the actual
status report the door was opened for discussion of whether other
addresses could be used and still be GOSIP V.2 compliant.  The answer
was yes.  Essentially, GOSIP does not preclude any NSAP structure.  If
IS-IS is to be used efficiently, however, the NSAP must carry a 6 octet
System ID field and a 1 octet network selector field in the last 7
octets of the DSP.

There was also some discussion on who or what organization has
responsibility for assigning addresses.  This was prompted by the fact
that the NSAP RFC simply points to GOSIP V.2 for NSAP format structure
rather than specifying the structure in the RFC. The reason is that the
Internet (thus far) is recommending use of the GOSIP format.  If the
format should change, then the RFC will not have to be republished.  In
the unlikely event that the GOSIP format should change to such a degree
that the Internet experts are uncomfortable with it then the NSAP RFC
could be modified to reflect the required format rather than point to
GOSIP. Following the discussion a vote was taken on whether or not to
recommend to the IESG to advance the NSAP Internet Draft to RFC status.
The vote was 17 for and 0 against.

NSAP Guidelines Status

Not much was done since the last meeting.  After some discussion it was
agreed by consensus that the NSAP Guidelines paper would be updated.
All editors' comments would be resolved and the paper would be mailed
out for review by the end of August.  A Working Group meeting is

                                   1






tentatively planned to be held at INTEROP in October to review the
document prior to the December IETF meeting.

NSAP Administration Proposal

Richard noted that, under current GSA guidelines for administration of
GOSIP NSAPs, GSA will entertain proposals from any organization wishing
to be assigned AA values under ICD 0005.  He recommended that the
Working Group develop such a proposal, which would be the administrative
counterpart to the NSAP Guidelines paper.  The proposal would request
one or more AA values from GSA and elaborate on how these would be
administered.  An organization that is willing to provide the
administrative support should be identified to submit the proposal to
GSA. NSF was suggested as a possible candidate, and there may be others.

Sue Hares (Merit) volunteered to begin drafting the administration
document.  If you would like to contribute she can be reached at
[e-mail].

4.  Address Transition

This subject had arisen on the Working Group mailing list and Richard
wanted to ensure that there was no disagreement before updating the
Guidelines paper.  Subsequent to the explanation of the issue, which is
detailed below, there was no significant discussion and no disagreement.

Address transition has to do with the interaction between hierarchical
address assignment and the way IS-IS routers handle areas that move from
one routing domain to another.  For example, assume an area, represented
by the area address ABC (i.e., a prefix), moves to another routing
domain and retains its area address.  If the area address is allocated
from the (shorter) prefix of the original routing domain, AB (i.e.,
hierarchical address assignment), two problems are created.  First, in
the source routing domain, the ISs must advertise externally to other
routing domains that they can reach all addresses that start with AB
*except* the addresses that start with ABC (i.e., the recently-moved
area).  Second, in the destination routing domain, the ISs must
advertise externally to other routing domains that they can reach all
those addresses that they could reach before, e.g., those that begin
with prefix XY, but *also* the area address of the newly-acquired area,
ABC.

If there is no address reclamation, over time this will lead to
``address entropy'', or flat addressing.  Any gains in address collapse
from originally allocating addresses hierarchically will eventually
disappear.  It is, therefore, necessary that the area eventually
relinquish its old area address to the original routing domain.

Attendees


Nick Alfano              [e-mail]

                                   2






Colin Amor               uunet!rti.rti.org!bnrunix!cja
Ross Callon              [e-mail]
C. Allan Cargille        [e-mail]
Richard Colella          [e-mail]
Curtis Cox               [e-mail]
Nick Di Iorio            [e-mail]
Dennis Ferguson          [e-mail]
Ella Gardner             [e-mail]
Michael Grobe            [e-mail]
Robert Hagens            [e-mail]
Susan Hares              [e-mail]
Ken Jones                uunet!konkord!ksj
Paulina Knibbe           [e-mail]
Jim Knowles              [e-mail]
Chuck Martin
David Miller             [e-mail]
Cyndi Mills              [e-mail]
Douglas Montgomery       [e-mail]
Mark Needleman           [e-mail]
Rebecca Nitzan           [e-mail]
Yakov Rekhter            [e-mail]
Jim Sheridan             [e-mail]
Jim Showalter            [e-mail]
Keith Sklower            [e-mail]
Erik Skovgaard           [e-mail]
Zaw-Sing Su              [e-mail]
Justin Walker            [e-mail]
Linda Winkler            [e-mail]
Jean Wu                  [e-mail]



                                   3